Serverless Meetup Tokyo #4 レポート #serverlesstokyo
こんにちは、臼田です。
Serverless Meetup Tokyo #4が開催されましたのでレポート致します。
セッションレポート
体育会系サーバーレス:汗、友情、勝利、テニス
竹原竜児氏 (ソニー)
- Smart Tennis Lesson(STL)で利用しているサーバレスについてのお話
- STLとは
- 2017 3月より全国導入
- ルネサンスにて導入
- Serverlessへの期待と疑問
- 期待
- 自社の問題領域の解決に集中できる、早くリリースできる
- NWレイヤまでの保守運用、脆弱性対応などを限りなく0に近づける
- インフラコストが安くなる
- SWアーキテクチャ上 凝縮度が高い、結合度低い設計に誘導される
- 疑問
- SQLベースのB2B2Cという固めの案件にうまくServerlessで対応できるのか?
- 期待
- 今日の発表内容
- SQL DBを使ったサービスへのServerless導入が成功するまでの重要アクションとTipsを共有
- 汗
- Serverlessに適合させたテスト、運用!
- 友情
- 既存SQLスキルをデータ連係、グループアクセス制御
- 勝利
- パフォーマンス向上
- STL System構成
- テニスコートにIoT機器
- テニスネットのポールにカメラを設定
- リアルタイムにストリーミングして動きを確認
- テニスのグリップにつけるセンサーでボールの当たった位置、スイングスピードなどを取得
- Bluetoothで送信している
- AWS側
- API Gatewayで取得してLambdaで処理、RDSに格納
- 家に帰った後も生徒さんが確認できるようにフロントも用意
- テニスコートにIoT機器
汗編
- ServerlessでもTest First! CI整備に汗をかく
- Nodeのテストツールであるmochaを利用
- LocalテストにはAPI Gatewayからのデータをダミーで渡して、Local, Remoteで同じテストコードで実施
- 判定はistanbulを利用, C0/C1共に80%以上にしている
- CIはapexを利用
- Serverless Frameworkと違いエイリアスに対応している
- API GatewayでCustom Domain Switchで切り替える
- Sig4Clientを入れて認証
- Lambda運用監視のお手軽構築テンプレを作る
- 標準のLambdaログだと見にくいので独自のLoggerで必要項目を必ず出力している
- リソースパスやログレベルなどを埋め込んでおく
- MetricFilters, Alarm, SNSはセットで構築できるようにCloudFormationテンプレートを用意
- 標準のLambdaログだと見にくいので独自のLoggerで必要項目を必ず出力している
- Serverless時代になってテストと運用設計スキルはより重要になってきている
- テストと運用の提携をプロジェクト初期に決めておいてテストを実行する
友情編
- ServerlesにSQL(Aurora)を組み合わせることについて
- いくらでもフロントがScaleするのにRDBはlimitが存在する
- VPC Lambdaを使わないといけない
- B2Bでのデータ連係で既存SQLスキルフル活用
- 主要な要件はSQLで完結、LambdaはSQL連続発行とログ出力だけ
- AuroraへのCSV->テーブルの取り込みはLOAD DATA FRO< S3文
- 認可、権限コントロールもCognito + SQLで強力かつ柔軟
- 効力に守るところはCognito, API GWに任せる
- DoSが来てもLambdaまで負荷は来ない
- 柔軟に表現したいところはSQLの関連としてチェックする
- 構造化された関連をたどるものはSQLなら1行で自然に表現
- 効力に守るところはCognito, API GWに任せる
勝利編
- VPC Lambda
- Aurora(RDS)を使うため必須
- API Callからデータにたどり着くまで長い
- Localでは100ms程度だがAPI経由だと1秒以上応答がかかる
- 10秒以上かかるときもある
- VPC Lambda ENIの仕組みを知る
- 分析にはCloudTrail
- Create/Delete NetworkInterfaceを調べた
- 対策としては定期的にENI, Lambdaを暖気
- Lambda初期化処理の場所にご注意を
- まだ1秒以上リクエストにかかっている
- 分析にはAPI GWのlateny logとLambda開始終了のタイムスタンプ
- 原因はORマッパーの初期化
- 対策は一度初期化したORマッパーをグローバルに保持するように変更
- 通信時間も含めて900-1200msから200-500ms程度での応答を達成
- Lambda対策 Tipsメモリけちるべからず
- メモリを上げるとインスタンスタイプが上がるのでCPUに依存したものも早くなる
まとめ
既存のベストプラクティスをServerlessに適用させることが重要!
感想
一般的にはLambdaとRDSを選択することは難しいですが、とてもいい成功事例だと感じました。
ベストプラクティスを忘れずに実践していきたいですね。
Test Driven Development For Lambda
堀家隆宏氏 (デジタルキューブ)
- 資料
- Serverless Frameworkの日本語フォーラムを運営している
- Lambdaを使ったテストについて話す
- なぜテストをするか
- 継続的に開発を行うプロジェクトやプロダクトん質を保ちつつ改善のためのソースコードの変更を効率良く行うための土台を作る
- 例えば大きなプロジェクトだと多数のPull Requestが来る
- 人でさばくことはできないのでテストを作って自動化していく
- イベントドリブンで作ると疎結合なマイクロサービス群を統合してテストをするという、今までにあまり馴染みのないテストの考え方が必要になった
- アーキテクチャの特性上ソースコードの品質がシステム自体の品質にダイレクトに影響をおよぼすため、なんとなくでは済まされない部分が大きくなってきた
- インフラのせいにはできない!
- 継続的に開発を行うプロジェクトやプロダクトん質を保ちつつ改善のためのソースコードの変更を効率良く行うための土台を作る
- イベントドリブンアーキテクチャのテスト戦略ってどんなの?
- 全体のインテグレーションテストとLambdaのユニットテストを行う
- インテグレーションテストのポイント
- Serverless FrameworkやSAM等のデプロイツールを使いアーキテクチャを定義
- デプロイ、テストの実施、削除の流れをコード化する
- API GWのインテグレーションテストの例
- ユニットテストの流れ
- AWS APIへの接続をモックやLocalStackといった仮の環境で置き換える
- AWSリソースはテスト外として単純に処理の流れやエラー処理の分岐などをプログラムしようのテストに重点を置く
- AWS APIの存在を意識する以外はいわゆる通常のユニットテスト
- モックを作る例 AWS Lambdaのユニットテストのベストプラクティス(Node.js)
- これらのテストを組み合わせてどのようにTest Drivenにするか
- まずはインテグレーションテストを書く
- 逆にユニットテストからにするとモックの値の設計などができないので注意
- Lambdaは正常系のみをざっくり通りレベルでいい
- 次にLambda内のエラー処理について整理してユニットテストとプログラムをブラッシュアップ
- 最後にインテグレーションテストとユニットテストが通る事を確認して完成
- まずはインテグレーションテストを書く
- まとめ
- インテグレーションテストを行なってマイクロサービス全体を網羅するテストを行う
- ユニットテストはAWS APIに接続せずに純粋なプログラムの振る舞いのみ
- 開発の際はまずインテグレーションテストを書く
- 実践で使えるためには自分でテストを買い手体に覚えさせましょう
感想
具体的なテストの手法についても参考文献とともに解説されていて参考になります!
上記URLのgithubやqitaもよく確認したいですね!
Azure Cosmos DB + App Serviceの良い関係(仮)
三宅和之氏 (ゼンアーキテクツ)
- 開発事例について
- 富士フィルム「IMAGE WORKS」
- サーバ(VM)は一切使わない
- 規模
- 登録データ1TB/day
- ユーザ4万人
- フルPaaS構成での開発、リリース
- PoCから開発まで期間6ヶ月
- Keyとなったテクノロジー
- Cosmos DB (DocumentDB API)
- Azure App Service (Functions, Webjobs)
- NoOpsがコンセプト
- Azure Cosmos DB
- NoSQLデータベース基盤
- 低レイテンシ(SLA付き)
- 読み取り10ms以下、書き込み15ms以下(90%タイル)
- スケール
- グローバル分散
- Azure App Service
- アプリケーション実行基盤
- ほぼNoOps
- HotPoolベース
- いつも温まっている、暖気がいらない
- 複数のサービス形態に対応
- 付加機能が割りと充実
- アプリケーション実行基盤
- アーキテクチャ設計のポイント
- バッチ処理の設計
- オンプレミスとの動機処理はQLL(queue-based load leveling) + Scale-outで実装
- キューの待ち行列が指定した長さを超えたらスケールアウト
- Cosmos DBはスパイクに対応できる予約ノードを利用できる
- Queue + Funcetionsのいいところ
- ループが一切なくなるのでここのプログラムが短くなる
- インフラの機能だけで処理量を調整できる
- フロントエンド設計
- SAPを利用
- 機能毎に使うサービスを分ける
- グローバル分散・DR
- Traffic Managerを活用
- DNSレベルでエンドポイントをルーティング
- グローバル分散NoSQLデータベース・サービス
- Traffic Managerを活用
- バッチ処理の設計
- 「高弾力性設計」実現のために考慮したこと
- エンドポイントは軽い処理のみ
- 非同期分散処理が基本
- Workerの粒度は小さく
- 処理はStateless
- 接続もStateless
- Stateはデータストアで管理
- Design principles for Azure applications
感想
Azureでも楽しくServerlessできそうなお話でした。
Design principles for Azure applicationsは一般的にも活用できる内容のようなので、必見ですね。
The Architecture of Serverless React SPA
池内孝啓氏(slideship)
- 資料
- slideshipとは
- プレゼンテーションのスライドをwebで作れる
- markdown対応
- syntax highlightしてくれる
- Principal
- クラウドネイティブ
- Serverlessがいい
- URIに神が宿っている
- State-less
- サーバはJSONを返す
- HTMLのクライアントサイドはSPA
- CDN使おう
- Infra
- CF, S3
- ALB, EB, Lambda
- Aurora
- Appications
- EBはGo
- CloudFrontではRESTとSPAの2つを処理
- 環境はバージニアに乗っている
- 新しいものが一番早く使えるから
- レイテンシーは気になることはあるが基本はCFが利用できるのである程度緩和できている
- God is in the URI
- URLの見た目にこだわっている
- DEMO
- webから編集できる
- スライドの入れ替えもドラッグ・アンド・ドロップで出来る
- P○werP○intみたい!
- レイテンシーは気にならない
- Alt-Serverside Rendering for OGP Optimization
- サーチエンジンのオプティマイズの闇
- Googleの検索エンジンが対応していなくてうまく動いてくれなかったが最近はJSを評価してくれている
- 動的なOGPを読んでくれない(Twitter, FB, Slack等)
- Server Side Rendering(SSR)
- Serverlessじゃなくなるので採用したくない
- Prerendering
- アクセス権限の問題などで懸念点が残る
- 自前で実装した
- Prepared Multiple Entry-point
- という名前にした
- プリ生成したものをS3に置いておく
- OGPについても記載しておく
- コンテンツ本体はJSで取ってくる、あくまでOGP対応のため
感想
シンプルで面白いwebスライドのサービスですね。
Markdownで書けるのも楽しいですね!
Serverless Application with Chalice
西谷圭介氏 (AWS)
- Chaliceの紹介
- AWSが提供するオープンソースのサーバーレスアプリケーション開発フレームワーク
- Python向け
- 7/31にGAしたばかり
- Chaliceというコマンドラインも提供
- コードの自動生成
- IAMポリシーも自動生成
- APIバックエンドの構築
- デコレータにより作成したファンクションとAPI GatewayのAPIを簡単にルーティング
- chalice deploy
- デプロイ用のコマンド
- 依存関係の解決なども行う
- シンプルなファンクションも書ける
- Scheduled Event
- スケジュール実行も書ける
- Automatic Policy Generation
- コードをスキャンしてAWSコールを検出
- 必要最低限のIAMポリシーを自動生成
- 自分でIAMポリシーを当てることも可能
- CI/CD
- CIパイプラインの作成
- Code兄弟を使ったパイプライン
- 実際にはCFnテンプレートで動作
感想
シンプルで強力なツールなので、Chaliceすぐに検証したいです!
1日1億イベントを捌くサーバレスアーキテクチャ
なりたけいすけ氏 (CyberAgent)
- アメブロのエンジニア
- AmebaにServerlessを導入した話
- アメーバブログ公式ジャンルを公開した
- ジャンルごとにランキング
- Lambda中心にサーバレスで構築
- 様々なところからAPIが呼ばれるので、どれだけリクエストが来ても耐えれるようにしたかった
- 一つのページから5つのAPIリクエストがあったりする
- 大量のEC2は絶対管理したくないのでLambdaを利用した
- Serverless Frameworkを利用
- 一応載せ替えても動くようにnode.jsの中身を構築した
- 1億/1day
- スロットリングだけ気をつけていれば問題ない
- HealthcheckもLambdaからSlack通知
- DynamoDBのアラートもLambdaで自動調整
- 公式でAutoScale対応したから今はいらないかも
- レポートもLambdaからSlack
- BatchをDynamoに適用
- S3チェック
- Athenaも使ってレポートしている
- Serverlessのつまづき
- Lambdaのストレージ要件を超えることがあった
- 75GB上限
- Lambdaのバージョン情報が影響していた
- デプロイ中に古いバージョンを上書きしたのでON
- デプロイ完了したら古いバージョンを消すようにした
- リソース上限を超える
- 200リソースを超えるので役割毎作る
- TeraFormと被る
- EC2はTeraform
- Serverless FrameworkはLambda管理
- サービスが一杯で大変
- 頑張って覚える
- Bookkey
- ディスプレイの前を通ると風や音がなる
- Lambdaのストレージ要件を超えることがあった
- メリット
- どこかが壊れても大丈夫
- サーバ管理しなくていいのが楽!
インフラエンジニアがRails周りで頑張る
高橋恒樹氏
- 標準的なRalis環境周りで奮闘した
- Deploy・運用一般
- Slackからデプロイ
- Slackから管理サーバのIP制限を解放
- 塞ぐのはCloudWatch Eventで定期的に実行
- 中国ユーザ対応
- 見えない壁でCloudFrontが効かない
- 中国リージョンでS3を置く
- まとめ
- バリバリサーバアプリケーションの運用を担当している
- エンドユーザの目に触れる形でもデビューしたい
flowtypeStepFunction
尾崎耕多氏 (ChatWork)
- 最近Lambdaの作り方が変わった
- Step Functionsで個別のFunctionに切り分けれるようになった
- 環境変数の対応
- SAMやその他のフレームワーク
- 1つのLambda Functionが小さくなってきた
- 一つの処理だけ行って結果を返すLambdaを使いまわせる
- こうなると、ユニットテストはいるのだろうか?
- 答えはflowtype
- node.jsに型をつけれる
- 型によって
- コードが正しいこと
- Eventのプロパティが正しいこと
- PutObjectが正しく呼ばれること
- callbackには結果が渡されること
- まとめ
- flowtype最高!!
サーバーレスの夢と現実
田中宏幸氏 (INFASパブリケーションズ)
- 2016年9月からサーバーレス
- ユーザはCFとAPI GatewayとS3を見ている
- SSRはLambda
- WordPressからAurora
- LambdaもAurora
- Auroraは危険?
- 最大接続数
- r3.xlarge * 3 = 6000
- ENI生成時間
- RDSへのIAM認証接続で解決
- いまはhot standbyしている
- latency
- 保証されていない
- latencyも安全にしたい
- でも、WPのDBをDynamoにはできない
- jsonにするところまでAuroraでjsonにしてからDynamoに入れる
- DynamoじゃなくてCosmosのほうがいいのでは?
- LambdaからCosmos呼んだらいいのでは?
- これってベストプラクティスなのかな?
- 最大接続数
- とりあえずAuroraと向き合う
- CFのCashes TTL = 86400
- WPで更新するとLambdaでキャッシュを消す
- ブログはじめました
全体の感想
今回はテストやデプロイ周りの話が多く、大変興味深かったです。
新しいフレームワークや手法はぜひトラッキングしていきたいですね。